The present invention relates to the general field of domain name servers in a telecommunications network. The Domain Name System (DNS) architecture defined by the Internet Engineering Task Force (IETF) Request For Comments (RFC) 1034 manages domain names in a network.
This architecture introduces the domain concept to designate a group of machines on the network.
FIG. 1 represents an architecture of this kind. The domains .,.fr,.com, ft.com, and rd.ft.com contain subdomains.
For example, the domain ft.com includes three subdomains www.ft.com, rd.ft.com, and user.ft.com.
The domains that are underlined in FIG. 1 are known as terminal domains. A terminal domain:                can represent one or more physical machines, like the terminal domain www.rd.ft.com, for example;        but can also not represent any physical machine, like the terminal domain user.ft.com, for example, which here consists of personal information of the person specified by “user”.        
A domain that includes one or more subdomains is associated with a domain server, also referred to as a name server.
The domain server includes a zone file.
The domains are logically linked, so that DNS data of any domain can be obtained by interrogating the name servers progressively, starting with the root server.
In the present document, the term information refers in particular to the IP (Internet Protocol) address of a domain, a text zone, or any field (CNAME, etc.) associated with a domain.
With the growing popularity of the Internet, domain name servers are increasingly difficult to administer.
In particular, update operations, which are additional to the traditional reading operations (directory function), considerably increase the number of transactions managed by these servers. Moreover, these transactions require operations to synchronize master and slave servers and also consume network resources.
Also, domain name servers host increasingly large amounts of data and increasingly large zones.
Previously, domain names contained hardly more information than IP addresses, not exceeding around twenty bytes. Nowadays, the DNS hosts much larger profiles (approximately 200 bytes), for example ENUM services (as described in IETF RFC 2916).
One known solution to this problem is to create subdomains, the name servers of the subdomains created in this way hosting some of the data previously hosted by the domain from which they originate.
That solution adds another level to the domain hierarchy, however, which complicates the new subdomain name.
This complexity of the subdomain name can be perceived as a drawback, especially if the name of the subdomain is used for commercial or advertising purposes.